The SRV file above must be very old (about two or more years, I'd say). It misses many items and I would also think it has items that were long ago moved elsewhere (CFG or TCD). Maybe you also have a FIL (filters) file in your Airio installation? If so, you need a serious config files update, because FIL is not used anymore.
It is probable I will release version 2.5.5 tonight, so far only the FULL and PROS version. You may check Airio log to see there are both minor and major updates included. Then 2.5.5 FREE will be released and I will send it all to Franky of 500servers to have it as the basic Airio version, with all the current config files for new installations.
It is probable I will release version 2.5.5 tonight, so far only the FULL and PROS version. You may check Airio log to see there are both minor and major updates included. Then 2.5.5 FREE will be released and I will send it all to Franky of 500servers to have it as the basic Airio version, with all the current config files for new installations.
There are too many things depending on real time cars processing, so disabling it is not possible. However, I believe admins/users have all the options to disable all the individual checks and messages that are a result of this processing.
Nice! Official patch is out for some time now, I have also updated Airio to be able to read layout data and possibly compare them to some fixed values that must be used for the layout track to be recognized as "official", with personal records, online world records and all. I've debugged many things, but almost surely I overlooked some others.
Now concerning the layouts, I would suggest the following: Let's concentrate on the ones that have PTH files ready and that can be now directly supported. These are A11, A12, A13, A21, A22, A23, B11, F11, K31, K32 plus all their reversed versions. To check layout, I intend to hard-code the positions of check points (splits) that must match with expectation. So the positions of split lines and finish line have to be correct and never changed.
To be extra sure I think also route checkers could be used? I do not have much experience with layouts, but if the route checkers are placed on some suitable places between checkpoints, Airio could also verify these and make extra sure the layout/track is valid. So I would suggest adding route checkers after every crossroad. Signs showing where to turn next and how far it is would be great to have for better orientation.
Then there's the question on B23 and B23R. As it is done now, it is not a track for racing but purely for stunts and crashing. Although I have the PTH file done, I'm not really happy about this track, it is not a rallycross alternate racing path, it is car and race destroyer. Fun, for a short time, but unsustainable for serious racing. My view. The option, I think, is to create barriers not allowing to cut the path, especially where BL2 joins with BL1 near pit exit.
New in LFS are extended clean lap checks that will be applied for all custom tracks. Specifically, going to ground (grass, it is the same check HLVC uses), touching wall, hitting any object. The ground check also presents problem for B23, at both places where the rallyx part goes to tarmac.
Now concerning the layouts, I would suggest the following: Let's concentrate on the ones that have PTH files ready and that can be now directly supported. These are A11, A12, A13, A21, A22, A23, B11, F11, K31, K32 plus all their reversed versions. To check layout, I intend to hard-code the positions of check points (splits) that must match with expectation. So the positions of split lines and finish line have to be correct and never changed.
To be extra sure I think also route checkers could be used? I do not have much experience with layouts, but if the route checkers are placed on some suitable places between checkpoints, Airio could also verify these and make extra sure the layout/track is valid. So I would suggest adding route checkers after every crossroad. Signs showing where to turn next and how far it is would be great to have for better orientation.
Then there's the question on B23 and B23R. As it is done now, it is not a track for racing but purely for stunts and crashing. Although I have the PTH file done, I'm not really happy about this track, it is not a rallycross alternate racing path, it is car and race destroyer. Fun, for a short time, but unsustainable for serious racing. My view. The option, I think, is to create barriers not allowing to cut the path, especially where BL2 joins with BL1 near pit exit.
New in LFS are extended clean lap checks that will be applied for all custom tracks. Specifically, going to ground (grass, it is the same check HLVC uses), touching wall, hitting any object. The ground check also presents problem for B23, at both places where the rallyx part goes to tarmac.
LOL, Mischa, you're absolutely right, same here. 
Victor, great explanation and awesome suggestions, thank you! 
In short, make one big static buffer, always fill it with everything available and process the data. Nice.
As for the erroneous disconnects, I meant that my earlier code was not processing split packets correctly, so it lead to bad packets being detected, especially when run remotely, which meant disconnects, probably just because of bad code and not bad packets.
In short, make one big static buffer, always fill it with everything available and process the data. Nice.As for the erroneous disconnects, I meant that my earlier code was not processing split packets correctly, so it lead to bad packets being detected, especially when run remotely, which meant disconnects, probably just because of bad code and not bad packets.
Hmm, I'm really not sure when it happens. Airio had troubles with remote connection to servers (running on another PC, data transferred over the Internet), especially when the connection was not perfect. I guess split packets were more frequent then, leading to erroneous disconnects for bad packets. But it may as well be just my imagination.
Well, yes, I do that packet size check later on when the read packet is actually being processed, this is just TCP (whole) packet reading code.
Also, I added code to notify me about split packets and indeed it happens sometimes. It seems the code is now correctly handling both split and merged packets though, so it was a great note/tip Scawen made.
Version 1.5.2 (maybe) corrects the TS3 new client version problem. Please check it out and let me know if it still doesn't work properly. I have one another bug reported, saving wrong best lap data for comparison, maybe from qualification. I still have to check and debug this.
Thanks, I have the same feeling, downloads and the panel work smoothly again.
Any idea if the lag issues are solved now? The admin panel seems much more responsive today. I was also testing some file download and it looked OK, while yesterday it did not really work...
Demo version does not support layouts nor open tracks.
I've noticed this also earlier, though there are no doubt exceptions: Posting any code makes the thread die! 
You mean to allow/support voting for special "official" custom layouts on open tracks?
Aonio 1.5.1 has updated library files working properly on 0.6B and newer clients. Also, pressing Ctrl+Shift now switches between nicknames and usernames in the field (race position) panel. Other fixes hopefully coming soon.
As the official 0.6B patch is available, I updated the library files that Airio is using and called this a version 2.5.4. But it is just library updates, the program files are still the same as in 2.5.3 and even !ver will show this old version, but new library version. It is just a quick fix that was necessary, because older libraries will NOT work properly on new host versions, 0.6B and newer, Airio will keep disconnecting. To solve the problem, the Aegio InSim library needs to be updated, using the files linked in my signature.
Corrected for version 2.5.5.
Yes, I corrected this earlier, it will be available in version 2.5.5.
Here's another replay of the buggy start, when the timer starts to run actually 1.5 to 2 seconds after green lights. It seems it is not such a rare bug as I thought, when I asked people to watch for it they could see it pretty soon.
OK, just the packet(s) reading code, merging and splitting them as needed:
No guarantees though that this is 100% correct, I may have overlooked something.
byte[] buff = new byte[256]; // number of bytes read stored in bts
int bts = tcp.Receive(buff, 1, SocketFlags.None); // InSim packet length stored in buff[0]
if (bts == 0) { return new byte[0]; } // disconnect
while (buff[0] > bts) // read from TCP until packet length
bts += tcp.Receive(buff, bts, buff[0] - bts, SocketFlags.None); // read only one packet
Array.Resize(ref buff, bts);
return buff;No guarantees though that this is 100% correct, I may have overlooked something.
Last edited by EQ Worry, .
Thanks for getting back to the matter.
I understand, it was required too late and it's not as easy as it may seem. It would be great though to keep it as a future feature. The tweaked bit could be used to e.g. disable lap time storing (maybe also for LFSW). Demo bit would allow easy detection of demo-compatible host setup, which is now impossible (or at least complicated). One final thing missing is a report of currently allowed cars on host, many people find it strange this important info is not in fact available. Also, reporting things as vote, midrace join, car reset, etc. only on race starts is not ideal, I think, it all should be part of server state info state (with cars, demo, ...), sent on every change. Just my feeling though. I'm afraid I did not have as much time to be on patched servers, also rarely some such server got full enough. Last thing I remember was you mentioning that you're not sure why this message appears. Now I believe it happens only after pitting, when the car is quickly sent to spectate by an InSim. Just a feeling though.
Thanks again for all the InSim updates, some look really promising and some make me (and other server admins, I hope) feel safer. But I'm afraid the real hard test will start only when official patch is out and the current applications are extended to apply the new principles. Problems may appear then, when there are thousands of actions taking place. But so far everything looks good to me.
Final note, thanks for mentioning the split packet problem. (A friend of mine also mentioned the opposite may happen, two LFS InSim packets arriving combined.) While my library handled the 2nd case correctly, the 1st was actually not handled at all. Fortunately the code update was not too complicated, if anyone's interested, I could post the few lines of (supposedly correct) split/joined packet handling C# code here for review/discussion.
Good catch, Daniel! Especially in the 1st replay the delay seems to be about 1.5 seconds, easily noticeable. But I've had even worse delays, strange thing. 
Probably it is too late, but I remembered one rare bug. Sometimes (1 of a 1000 races) the race time is delayed, usually by 2 or 3 seconds. I mean race starts, cars go properly, but race time stays at 0:00.00 for 2-3 seconds, only then it starts counting. The result is impossible lap 1 time and impossible race time too.
Airio has no "Danger, someone lost control message", that's purely Lapper feature which I never wanted to implement because of its very low value bordering on pure spam. I'm afraid you need to ask the drift server admins to remove that default Lapper definition.
Yes, it was just the 5Z to 6A transition causing problems with new packets. The quick patch just disables erroneous Airio disconnects. I have much improved library version now, recognizing and completely processing all the new packets, also properly handling split (and merged, if they're possible) TCP packets. In a few days there'll be Airio 2.5.4 with this new library, not with so many new things, but fully compatible with 6A and future (uhm) LFS versions. This will be basically the lowest possible version to run on 0.6A+ LFS patches.
Uhm, wow, I don't think that would be practically usable thing. Let me think about it, but...
One documentation note: If I'm not mistaken, the new admin commands (such as /cv and /ck, maybe others [tweak]) are mot mentioned in the server docs nor shown on /help lines. 
Otherwise I found no bugs in the new InSim packets so far, even though e.g. the hit object is surprisingly often reported with index 0, unknown, despite it being a standard tyre stack or cone/pole on BL1.
The only thing I miss now is more info about current server state (demo, tweak, vote, midrace, ...), updated on every change. And the user license status in LFSW data, which Victor hesitates to add.
Otherwise I found no bugs in the new InSim packets so far, even though e.g. the hit object is surprisingly often reported with index 0, unknown, despite it being a standard tyre stack or cone/pole on BL1.
The only thing I miss now is more info about current server state (demo, tweak, vote, midrace, ...), updated on every change. And the user license status in LFSW data, which Victor hesitates to add.
FGED GREDG RDFGDR GSFDG